资深架构专家聊架构之道：规划、简化和演化（续）

李晓时，超过 20 年 IT 行业经验；资深架构专家，《架构宝典》联合作者。

上文 《资深架构专家讲解微服务治理的架构演进》分享了架构规划

11

规划还是演化？对架构影响的思考

演化这个词越来越流行了，但仔细想一想，有些情况演化的周期是很长的。就像不可降解的塑料制品，其以无害身份重新回归自然需要几百年甚至更长的时间。考虑演化时，也要结合软件/应用系统的生命周期，否则失去意义。

12

缺少规划，难以演化

单靠演化，即使能使架构越来越优化，也可能需要很长的周期，而对于产品或者项目，时间这个约束条件往往是苛刻的。

如前面所阐述，迭代是有条件的。我的建议是：在有规划的基础上进行演化。我们无法得到普适的架构，但可以得到确定领域的通用架构，可以在特定领域通过演化使应用架构逐步优化，逐步与业务架构想适应，提高匹配度。

13

简化架构是必要的

简化架构，应该成为架构师的常识和日常必须考虑的事情。复杂的架构，特别是强依赖对业务的影响很大：

• 维护成本增加

• 集成测试/回归测试成本增加，即使对于微小的改变

• 引入 BUG 的可能性增大

• 对于缩减投资的系统存在单点故障的可能性增大

• 难于在复杂的系统架构和业务间转换

• 管理和审计难度大成本高

• 难于用新技术替换不被支持的过时的技术

13.1

常用分布式组件互操作及接口定义

分布式的计算模型是以 RPC 为基础展开的，为解决应用系统间的集成和互操作，为支持语言和平台独立性，经历了几十年的发展历程，从 RPC 到 COM/COM+，以及 CORBA 和 JavaBeans/EJB，进而发展到 Web services，实现了跨平台及语言无关。

如果不支持互操作，那么基于异构组件搭建分布式计算平台就是不可能的。

14

服务化/分布式的网络基础

无论服务化还是分布式，都需要进程间通讯（IPC），也包括线程间的通讯。这样，一个好的通讯协议是必要的。HTTP 协议的设计初衷据说是为了人-机通讯，后来被用作机器间通讯（M2M），这是服务化/分布式的网络基础。

其他协议，也可以担此大任。只是从复杂性、使用难易程度、普遍性等方面要多加考虑。比如传统的 web services，其 SOAP 协议除了可以基于 HTTP，还可以基于 SMTP。

15

从架构角度解决企业应用痛点

通过调研，我们发现企业应用系统面临的三个主要痛点：

1. 灵活性差

2. 交付时间长，动辄 3 个月或者半年乃至一年

3. 性能差，用户体验不好

针对灵活性差，我们提出要降低耦合度，这也是软件工程中的一个基本原则。这样的问题，反映出我们的软件设计、开发水平不高的现实，专业性差，很多时候，很多开发人员还分不清程序和软件的区别，还只停留在功能实现的低水平上。这不单是靠架构优化能解决的，而是要靠提高整体开发水平来解决。

针对交付时间长，我们考虑从提高重用和构件化等方面着手，不断积累企业应用构件库。这好比我们烧砖建房，我们从实际需求出发，逐步建立并不断更新有限的砖块规格集合，未来所有的房屋都使用标准件来搭建。

针对性能问题，我们在构件化的基础上逐步地适度地服务化，这样讲是因为我们认为，不是所有的应用系统都适合服务化。有了这样的基础，我们对系统的扩展，包括水平和垂直，都会变得容易，分布式的部署水到渠成。

16

企业应用架构服务化迁移步骤

通过前面的痛点及解决方案的分析，我们总结了好的企业应用架构的三要素，同时也作为我们的三步走战略：

1. 组件化/构件化

2. 服务化

3. 分布式环境

“对象-组件-服务”示意图希望表达三者之间的关系，有助于理解组件化是服务化的基础。对于非面向对象语言程序设计，也可以支持服务化，此处不做深入探讨。

服务化是和多进程/多线程相关的，是降低应用部署粒度的过程。而分布式部署，其基础是进程/线程间的通信。要理解 RPC，最好首先理解 IPC，这个前面已有论述。

17

企业应用系统服务化参考模型

这是我们针对企业应用系统服务化而开发的模型，考虑了多种逻辑和物理架构。结合企业应用，基于多层分布式体系结构而进行的实例化。我们希望该模型能够覆盖企业的全部应用，包括基于 package 的二次开发系统（如 SAP，Oracle），基于 SaaS 的云应用（如 SFDC），以及基于 Java/.Net 自开发的一些应用。我们正在实践中逐步完善这个模型，希望能为企业架构的优化助力。

18

浅谈几个相关的概念

这里希望对这几个相关的概念做简单的对比，以便大家在学习、看文章时、讨论时，能够在合适的语境。

9

Web Service 与 Micro Service

Web Service，由于需要 WSDL 以及 skeleton，导致比较“重”，但支持复杂的数据结构。

Micro Service，主要是指粒度小；再有就是不需要 WSDL 以及 skeleton，因此轻量。

对于微服务（Micro-services）和大数据(Big Data)这 2 个术语的理解，不能望文生义。微是为了表示粒度的足够小，但小到什么程度合适，一方面见仁见智，另一方面应该结合实际项目实际问题。拿瓷砖和马赛克为例，我们不会在需要使用瓷砖的地方都使用马赛克来拼凑。

"webservice" and "microservice" aren't mutually exclusive terms, nor do they have strict, objective definitions. It's possible that all of your web services already are microservices by many people's definitions.

Web services architecture: the service provider sends a WSDL file to UDDI. The service requester contacts UDDI to find out who is the provider for the data it needs, and then it contacts the service provider using the SOAP protocol. The service provider validates the service request and sends structured data in an XML file, using the SOAP protocol. This XML file would be validated again by the service requester using an XSD file.

How big is a microservice?

Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.

This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.

10

Web Service 与 SOA

这里想强调的是 SOA 与 Web Services 不是一个概念，很多时候，这 2 个概念却常常被不恰当地混用。

The vision behind SOA and Web Services comes from enterprise and organization needs to save development effort and money by reusing software in the form of components.在 SOA 和 WebServices 背后的想法是，企业和组织希望通过复用组件以达到节省成本的目的。

The Web Services vision achieves reuse by building service components that autonomously discover at runtime other needed components needed to solve a business process.Web Services 的愿景是，通过构建服务组件，支持自动发现解决业务流程问题，实现对复用的支持。

The SOA vision achieves reuse by aligning new software development projects to business goals through a governance plan. SOA 的愿景是，通过治理使新的软件项目和业务目标一致

Both expect a registry of services will help avoid building the same software component twice.

二者都希望通过注册机制避免同一个的组件开发两次（重复开发）。

11

Micro Service 与 SOA

在 Sam Newman 的《Building Microservices》一书中，SOA 和 Micorservices 的区别给出了定义：

You should instead think of Microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.

你可以把微服务想成是 SOA 的一种实践方式，正如 XP 或 Scrum 是敏捷软件开发的实践方式。

面向服务架构（SOA）的概念已有十多年，它提出了一种架构设计思想， 但没有给出标准的参考实现，当微服务架构出现时， 其拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签，而直接称其为微服务架构（Microservices Architecture Style）， 让人以为是一套全新的架构思想，但事实上它的本质依然是 SOA 的一种实践方式。

The core difference between SOA and microservices lies in the size and scope. As the word "micro" suggests, it has to be significantly smaller than what SOA tends to be.

Microservice is a small(er) independently deployable unit. Beware of very small microservice antipattern - nanoservice.

A SOA can be either a monolith or it can be comprised of multiple microservices.

12

SOAP 与 REST

SOAP, or Simple Object Access Protocol, is an architectural concept that was created in 1998 by Dave Winer, Don Box, and Bob Atkinson, in collaboration with Microsoft. Designed explicitly for the purpose of making communication between web services easier.

SOAP，简单对象访问协议，是在 1998 年由 Dave Winer, Don Box, and Bob Atkinson, in collaboration 在微软公司合作时创造的架构概念，设计的初衷是为了 web service 之间通讯更容易。

REST, or Representational State Transfer, was created in 2000 by Roy Fielding in UC, Irvine; later versions of this architecture were created in collaboration with the W3C Technical Architecture Group (TAG).

REST，表述性状态转移，由 Roy Fielding 在 2000 年在 UC, Irvine 创造，后续的版本是与 W3C 的 TAG 合作推出的。

While SOAP aimed to be a complete system, REST was designed to be more lightweight for building the following right into the design.

SOAP 的目标是一个完整的系统，而 REST 倾向于更加轻量。

Extensibility through user generated extensions tying into the base structure;

Neutrality by operating over any transport protocol;

Independence by allowing variable programming paradigms and structures;

Large Data Handling by handling conversions, calculations, etc. asynchronously;

Scalability by using cached data from the client and intermediate nodes built into HTTP to self-define;

Portability by tying the transfer of data to the program code during transfer;

Extensibility by allowing individual elements of the greater network to develop independent of one another, using uniform interfaces.

13

参考资料

Martin Fowler:

https://youtu.be/2yko4TbC8cI?t=15m53s

Edit : Here is another video by Martin Fowler, talking about difference between Microservices and SOA.

https://youtu.be/wgdBVIX9ifA?t=13m10s

---

推荐阅读